The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically simplified scheme showing a generic deployment of an IMS common core, signalling and media gateways to an external network (1) or access network. A User Equipment (UE) 2 attaches vies a Proxy-Call/Session Control Function (P-CSCF) 3, which operate as a SIP proxies within the IMS control layer. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) 3 which is the first point of contact within the IMS for a SIP terminal; a Serving CSCF (S-CSCF) 4, which provides services to the user that the user is subscribed to, and the Interrogating CSCF (I-CSCF), not shown, whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The application layer includes the IMS service network. Application Servers (ASs) 5 are provided for implementing IMS service functionality. The entities within the connectivity layer that connect the UE 1 to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. A description of the functional entities can be found in TS 23.002.
The IP Multimedia Core Network (CN) Subsystem comprises all CN elements for provision of multimedia services. This includes the collection of signalling and bearer related network elements as defined in TS 23.002. IP multimedia services are based on an IETF defined session control capability which, along with multimedia bearers, utilises the IP-CAN. In order to achieve access independence, and to maintain a smooth interoperation with wireline terminals and wireless terminals across the Internet, the IMS attempts conforms as far as possible with to IETF “Internet standards”.
The IP multimedia core network subsystem (IM CN) allows PLMN operators to offer multimedia services based on and built upon Internet applications, services and protocols. While the IM CN does not standardize such services, it enables convergence of, and access to, voice, video, messaging, data and web-based technologies for wireless users, and combines the growth of the Internet with the growth in telecommunications.
Lawful Interception (LI) allows Law Enforcement Agencies (LEAs) to obtain communication network data for the purpose of analysis or gathering evidence. The data typically includes details of signalling, such as called and calling parties, and in some instances the contents of the call itself.
3GPP TS 33.107 “Lawful interception architecture and functions” describes the architecture and functional requirements with a Third Generation Mobile Communication System. FIG. 2 shows a simplified architecture when LI is implemented in an IMS network. A Law Enforcement Monitoring Facility (LEMF) 6 may be located in a 3G network or any other network. An Administration Function (ADMF) 7 communicates with the LEMF 6. Note that more than one LEMF is shown because the ADMF 7 may communicate with several different LEMFs. Owing to different legal LI requirements, the LI information shared with different LEMFs may be different. For simplicity, the following discussing refers to a single LEMF 6. The ADMF 7 communicates with the LEMF 6 using a Mediation Function (MF) 8 via a HI1 interface.
Delivery Function DF2 9 communicates with the LEMF 6 via a HI2 interface and is used to send Intercept Related Information (IRI) to the LEMF 1 using a MF 10. DF2 4 receives IRI from a CSCF 11 in the IMS network via an X2 interface. IRI may be triggered by events that are session related or session unrelated. Note that the configurations shown in FIG. 2 only depicts a logical representation of the entities involved in lawful interception; these may or may not be implemented as separate physical entities.
Another function of the ADMF 7 is to hide from the CSCF 11 the fact that there may be multiple activations by different Law Enforcement Agencies (LEAs) on the same target. The ADMF 7 may be partitioned to ensure separation of the provisioning data from different agencies. In the figure, the HI2 interface represents the interface between the LEA and the delivery function. The delivery function is used to distribute the IRI to the relevant LEA(s) via the HI2 interface.
The architecture shown in FIG. 2 allows that provision of IRI for SIP messages handled by the CSCF 11. Interception of call content (CC) for this case can be done at the GPRS Support Node (GSN) under a separate activation and invocation, according to the GSN, lawful architecture. For the IMS domain interception the CSCF 11 are the nodes specified as Intercept Access Points (IAPs) according to 3GPP TS33.107 for general interception in IMS. Such nodes can provide information related to the start and end of a SIP session, and copy the exchanged signalling. However, they cannot be aware of the actual service executed by the AS 5 handling the session for a specific intercepted communication session. The analysis of the intercepted SIP signalling intercepted in the CSCF 11 could give only a best effort interpretation of which service is executed by the AS 5.
To address this problem, 3GPP TS 33.108 introduced a new IMS conference interception specification that requires a different Intercept Access Point. The architecture is illustrated schematically in FIG. 3. When a user is taking part in a conference call, an AS 5 handles the conference call. The key elements for interception of conference services are the AS/Multimedia Resource Function Controller (MRFC) 12 and Multimedia Resource Function Processor (MRFP) 13. IRI associated with the conference services that are to be intercepted are reported by the AS/MRFC 12 while the call content associated with the conference service is reported by the MRFP 13 via DF3 14 and MF 15. Certain events must be reported as IRI. These include a notification of when a target requests that a conference be created, when a target successfully provisions a conference, when a target provisioned or requested conference is started (i.e., the first party is joined to the conference), when a conference that is a target of interception is started (i.e., the first party is joined to the conference), when interception is activated (on a conference or a conference owner) during an ongoing conference, and when parties have joined a conference and communication is started or enabled by the conference server in cases where the conference is a target of interception or when it is a target's conference.
If the target of interception has provisioned or requested a conference to be created, interception of IMS Conference Services begins regardless whether the target of interception has joined the conference. Interception of IMS Conference Services continues if the target of interception is on hold and the conference continues.
Further IRI that must be reported include the identity of current and potential conference participants, information about supported bearers, the conference initiator and/or controller, and a failure reason (if the conference should fail due to a problem).
The above information can only be obtained from the AS 5 performing the services, and an MMTEL conference is only an example of a more general service interception principle highlighted in which only the AS can provide service specific info about the executed services because it has the role to trigger, control and maintain the service status, generates new legs accordingly and handles the service error cases.
A problem arises when an IMS network is implemented in more than one country. It is possible to deploy an IMS network by having a centralized IMS system in a unique country, and other IMS functionality in different countries, as illustrated FIG. 4, in which a P-CSCF 3 is located in country 2 but other IMS nodes such as the S-CSCF 4 is located in country 1. This network architecture is attractive, for example, where several small countries can share elements of an IMS network.
In the example of FIG. 5, core IMS functions are provided in Country 1, and other IMS functions are provided in other countries (countries 2 to 7 are shown by way of example). The core IMS functions in country 1 include the Applications Server 5, the S-SCSF 4, the MRFC 16 and the MRFP 17. Other functions, such as the P-CSCF 3, are located in each of the other countries.
LI regulations provide that each national authority can order the interception of targets only on networks element installed in that country. A problem is that LEAs in countries different to country 1 cannot start interception on the nodes located in country 1. The LEA in, for example, country 2, can only start IMS interception on the P-CSCF 3 or the MRF (if locally deployed).
As described above, there are requirements for conference interception in 3GPP TS 33.108 and for all the services in ANS T1.678 to provide information related to a service accessed by a target user and, ETSI 102 232-5 introduces the requirement to provide a unique CIN (Communication Identification Number) for the legs belonging to the same communication. According to the current 3GPP and ANS LI specifications the only node able to reliably provide such information is the AS 5 executing the service, but if a multi-country IMS network deployment is used, the only node available for signalling interception in the hosted country is the P-CSCF 3. This problem is illustrated in FIG. 5, which it is shown that a LEA in country 2 cannot obtain IRI via an MF/DF 19 located in country 2 from an AS 5 located in country 1.
For example, an LEA requires an interception for user A 20 in the country 2 and delivery of IRI in 3GPP HI format. User A 20 starts a 3PTY call or creates and enters an adhoc or scheduled conference with users B 21 and C 22, where B 21 is located in the same country as A, and user C 22 is located in a different country (in this example, it is country 5, although it could be any other country including country 1).
The P-CSCF 3, which is the only allowed IAP for the LEA in country 2, provides the SIP signalling messages copy but the ADMF 7 and MF 19 cannot set warrant nor receive information about the executed conference service on the AS 5 as the As 5 physically resides in another country. As result, no conference events can be delivered to the LEMF 6 by the DF2 and, in most cases, the LEMF will not know the identities of the conference participants, when the conference starts and stops and the other info needed by 3GPP LI standards. A further problem is that even if user B 21 is also a target, and is intercepted in the conference case above, the LEA will have no way of knowing that user A 20 and user B 21 are in conference together, even though they are in the same country.
Multi-media telephony over IMS [mmtel] is become increasingly important and has been adopted as the voice solution for Long Term Evolution (LTE), and so intercepting voice calls where an AS is located in a different country is important. As other services, such as messaging, chat, video, social applications and sensor based services become more common, it is also desirable to be able to intercept these even where an AS providing those services is deployed in a different country.
A further reason that it is necessary to be able to obtain IRI from an AS deployed in a different Country is that some LEAs use an ETSI 101 671 handover interface for IMS based telephony interception, which ensures that interception reports are received in the same format as reported for a circuit switched calls. If this is the case, then the service (e.g. call forwarding unconditional, call forwarding on busy subscriber, explicit call transfer, and so on) accessed by the user must be reported. This information is not present in the CSCF 11 and in the MRF, and it is not feasible to map available SIP signalling to this type of information. For this reason it is necessary to obtain IRI directly from the AS, but this is not possible when the AS is deployed in a different country.